Internet Info 1994 March

home *** CD-ROM | disk | FTP | other *** search

/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / networking / terms / kermit / e / cbx.mss < prev next >

Wrap

Text File | 1989-05-14 | 63.8 KB | 1,329 lines

@make(report) @style<Justification On, Hyphenation On, WidestBlank 1.4,Indent 0> @Define<Q,FaceCode R> @case[device, postscript="@style<spacing 1.2,spread 0.8,fontfamily NewCenturySchoolbook> @libraryfile<Accents> @define<q,facecode T>", x9700="@style<fontfamily univers10,spacing 1,spread 1> @define<q,facecode U> @modify<example,facecode U>", imagen300="@style<Fontfamily ComputerModernRoman12> @style<Spacing 1,spread 1,SingleSided> @define<q,facecode U>", file="@style<hyphenation off, justification off, spacing 1, spread 1>" ] @case<draft,2="@style(spacing 2)@modify(enumerate,spacing 2)"> @modify<example,above 1,below 1,group,leftmargin +2,rightmargin 0,spacing 1> @modify<heading,above 2,below 1,need 8> @modify<enumerate,above 1,below 1> @modify<subheading,above 2,below 1,need 6> @set<page=1> @begin(center) @begin<subheading> MAKING RS-232-C COMMUNICATIONS PACKAGES WORK WITH A DIGITAL PBX @end<subheading> Christine Gianone and Frank da Cruz Columbia University Center for Computing Activities New York, NY 10025 @value<date> @end<center> @blankspace(3) Organizations are people. What happens when a large organization embarks on a massive conversion of its data communications infrastructure? The ultimate effect is on the people sitting at their personal computers, running the software packages they are accustomed to, accessing the applications and services required by their work. Communications software packages represent an enormous investment in both time and money. Can this investment be preserved when an analog telephone voice network and a separately switched terminal network are replaced by a single digital voice/data private branch exchange? In this article, we will address a very specific concern: how RS-232-C communications software packages (see @i"Shopping for software that lets PCs with mainframes", December 1987) can be adapted to the new environment. Several years ago, during the early days of disvestiture, Columbia University began to investigate of the possibility of replacing its AT&T Centrex telephone equipment with a university-owned private branch exchange (PBX). Ownership of the switch and wiring plant has its advantages, primarily cost containment and operational control. The high capital expenditure could be offset over time by the expected savings in operating costs. Columbia's request for proposals included a requirement for simultaneous data and voice capabilities, as well as for extra wire pairs at each wall jack to accommodate future data expansion. The university is now in the throes of installing an IBM 9750 Business Communications System, which is composed of an IBM 9751 Computerized Branch Exchange (CBX) Model 70 connected to desktop ROLMphones (see @i<Inside IBM's new PBX, or the search for an office networking hub>, January 1988). When the project is complete, 75 buildings on and around Manhattan's Morningside Heights campus will be completely rewired, with the wiring plant extending to virtually every office, classroom, and dormitory room. For off-campus buildings, a total of a dozen cable trenches will be dug across the local streets. In all, 6,000 miles of cable will be laid. About 50,000 wire pairs will be connected to the main distribution frame in Columbia's central administration building, Low Library. One hundred thousand pairs of riser cables will be installed, and a similar number of station cables will be connected to about 13,000 voice/data jacks, about 3,500 of them in dormitories. Whereas data installations were once difficult or impossible, often requiring months of lead time, the new wiring plant will make them quick and simple. The cutover will affect all those who use the university's computers because the 9750 Business Communications System will replace not only the Centrex phone equipment, but also the Gandalf PACX IV data switch, which provides access to Columbia's central mainframe computers. Because of fundamental differences between Centrex and the new switch, the installation will also affect those who dial out from their offices to external services. When the new switch is fully installed, it will provide intra-switch connections, dialin connections, and dialout connections. Each of these presents its own conversion problems, and choosing among complicated options may be critical to achieving satisfactory data communications. Although the present discussion is specific to the IBM 9750 Business Communications System, it also applies in large part to the Rolm and IBM/Rolm CBX products, such as the CBX II 9000 and the VSCBX 8000. The problems addressed would likely surface during installations of digital PBXs from other vendors as well. For the remainder of this article, the IBM 9750 will be referred to as "the CBX." @subheading<Data Calls to Campus Computers> For the past 12 years, terminals at Columbia University have been connected to Columbia's central mainframes through a Gandalf PACX IV data switch. PACX connections come in the form of an LDS-125, a limited-distance modem on the user's desk with four wires carrying analog signals back to the PACX. To connect to a particular computer, the user turns on the LDS-125, types a carriage return for speed recognition, then gets a menu of the available systems, and is prompted to select one: @begin<example> Welcome to PACX IV SE. Valid node names are: HOSTA, HOSTB, HOSTC, MYHOST Enter node name => @i<(user types system name here)> @end<example> For example, the user might type MYHOST. The PACX maintains a table of computer host names and associated ports. When a known host is selected, the PACX finds the first free port and establishes a circuit between it and the user's terminal port, as shown in Figure @ref<-pacx>. When dialing in from off-campus, the LDS-125 is replaced by the user's modem, and the user dials the number of a modem hunt group connected to the PACX. Once the dial connection is complete, the procedure is the same. @begin(figure) @bar() @blankspace(1) @begin<example> __________ Gandalf PACX O | _____________________ O Host A | terminal ----- O O O | terminal ----- O O O__________| terminal ----- O O __________ terminal ----- O O O | : O O Host B | : O O | modem ------- O O O__________| modem ------- O O __________ modem ------- O O O | modem ------- O_____________________O O Host C | O | O__________| (** REPLACE WITH ARTWORK **) @end<example> @caption(The Gandalf PACX Data PBX) @tag<-pacx> @bar() @end(figure) Under the new regime, Centrex phones will be replaced with special units manufactured by IBM/Rolm, called "ROLMphones." These can be voice-only, or voice/data. The data option adds a 25-pin RS-232-C connector and accompanying electronics to the single-line or multiple-line voice telephone. Through a single pair of wires, a data-equipped phone can manage a voice conversation simultaneous with an asynchronous data connection up to 19.2 Kbit/s, using a proprietary protocol known as "ROLMlink." This single instrument replaces the Centrex telephone, the LDS-125, and the user's dialout modem. When the PACX is replaced by the new CBX, the dialog will change. As before, the user types a carriage return for speed recognition, but the prompt is different, and the user must type "call" in front of the hostname. @begin<example> CALL, DISPLAY OR MODIFY? call myhost CALLING 74258 CALL COMPLETE @end<example> In this case, the user types "CALL MYHOST". This superficial change in format should not pose an insurmountable problem. In all likelihood, users have been interacting with the PACX "manually" all these years, and conversion to the new switch will be a minor psychological adjustment. Dialing in from off-campus also remains the same as before except for the change in syntax. @subheading<The Modem Problem> Matters are more complicated for those who want to dial off-campus sites from campus phones. To understand why, it helps to know something about modems and their relationship to the CBX. A modem, or "modulator-demodulator," converts the digital signals of a computer's RS-232-C serial communications port to analog waveforms suitable for transmission on voice-grade telephone lines, and vice versa (Fig. @ref<-modem>). @begin(figure) @bar() @blankspace(1) @begin<example> RS-232-C Analog phone line RS-232-C PC----------modem---------------------modem----------host (digital (wavy analog waves) square waves) @end<example> @caption(A Traditional Modem Connection) @tag<-modem> @bar() @end(figure) Modems come in two major varieties: acoustically coupled and directly connected (Fig. @ref<-acmodem>). Acoustic coupling is susceptible to noise and vibration; therefore, it only works under good conditions, and only up to speeds of 300 bit/s or 1.2 Kbit/s. @begin(figure) @bar() @blankspace(1) @begin<example> @i<A picture of an acoustic coupler, an external direct-connect modem, and an internal modem> @end<example> @caption(Acoustic vs. Direct-Connect Modems) @tag<-acmodem> @bar() @end(figure) Whether internal or external to the computer, direct-connect modems reduce potential problems and increase the maximum speed by providing a direct electrical connection to the telephone wall jack. Furthermore, these modems have access to all the wires in the phone circuit, so they can simulate all the functions of a telephone: detecting and answering a ring, going off-hook, and even dialing a phone number. ROLMphones cannot be used with direct-connect modems, however, because the proprietary ROLMlink signaling that takes place between the telephone and the CBX is incompatible with the signaling methods used by modems (Fig. @ref<-rpmodem>). Thus, it serves no purpose to plug a modem into the ROLMphone's wall jack -- the modem and the switch will not be able to communicate. Hundreds of people at the university have direct-connect modems in their offices or dorm rooms. If they cannot use these modems with their new ROLMphones, then how can they call off-campus computers, outside data services, and computer bulletin boards? @begin(figure) @bar() @blankspace(1) @begin<example> Analog RS-232-C ROLMlink RS-232-C phone line PC----------ROLMphone-----------CBX-----------modem--------------- (phone line, cont'd) RS-232-C (** SEE ARTWORK **) ---------------------modem----------host @end<example> @caption(Dialing Out from the IBM Switch) @tag<-rpmodem> @bar() @end(figure) IBM's solution to the dialout problem is to provide the switch with a central outbound modem pool, in which modems are assigned dynamically to those who request them. The pool has many advantages: it is shared by all of the univerity's computer users, so economies of scale are achieved; it is centrally maintained; and it can be upgraded as new technologies appear. It may be used by anyone having a ROLMphone with the data option, plus a terminal or personal computer with a serial communications port and a modem cable. (Those who have an internal modem only, with no serial port, will have to get a serial port and cable.) However, the modem pool has one key disadvantage: the conventions used for call placement are not the ones used by the Hayes modem. This seems a trivial point until we begin to look at the popular communications software packages that are actually in use on campus. Most of these packages expect to be running on personal computers that are connected to Hayes or compatible modems and, therefore, "speak" to the modem using the Hayes AT command set. The switch, however, does not accept AT commands, and most communications software packages are not written with the IBM 9751 CBX call-placement dialog in mind. How can these software packages be made to work with the new CBX? @subheading<Alternatives> To accommodate software packages that require the Hayes command language for dialing, IBM offers the 244PC. This is a special four-line data-equipped ROLMphone which contains a built-in Hayes AT command set interpreter. But because this is a multiline telephone, the expense to the user is greater than for the normal single-line phone with data. It is also possible to furnish users with analog, rather than digital, telephone sets. But here too, the cost is higher than a for a digital line, in this case because extra interface cards are required in the CBX. Analog phones could be used with Hayes or other direct-connect modems, either internal or external. Furthermore they may be necessary for devices that use modems, but which use nonstandard data transmission techniques on the digital end, such as Telecommunication Devices for the Deaf (TDD's) that use a 5-bit Baudot code. And analog phones are also required for use with facsimile machines and other special-purpose devices that have built-in modems. As third alternative, it was discovered that the ROLMphone can be used at low speeds with acoustically coupled modems, or acoustic adapters for direct-connect modems. But these devices cannot be used for autodialing because the CBX does not respond to the pulse or DTMF dialing tones which are generated by autodial modems, in their mimicry of real telephones. Nevertheless, the growth of the digital PBX market could result in a mini-boom for acoustic couplers and adapters, catering to those who would rather live with low speeds and without autodialing than pay the monthly data service surcharge: one step forward, two steps back... In a large organization like Columbia University, a great deal of money can be saved by avoiding the 244PC and the analog phone wherever possible. This can be done if the popular communication software packages can be adapted to the CBX's normal call setup procedure. @subheading<Dialout Mechanisms> Why should there be such a fuss over what the user must type to place a data call? Let's look at the question in more detail. The dialing language of an autodial modem allows users to place calls by typing simple commands from a terminal or personal computer. But first, the cables must be correctly connected and the modem turned on (blunders along these lines can happen to the best of us). Then the communications software must be set for the desired transmission speed and parity, and the personal computer or terminal must be sending the Data Terminal Ready (DTR) signal to the modem. Then the software can be connected to the modem, and the user can type dialing commands. The Hayes AT command language is simple but powerful. A typical dialog with a Hayes modem (or a 244PC, which emulates the Hayes modem) goes something like this: @begin<example> ATZ F1 Q0 V1 X1 S0=0 @i<(User types modem initialization string)> OK @i<(Modem responds "OK")> ATDT 9,7654321 @i<(User types dialing command)> CONNECT 1200 @i<(Normal modem response)> @end<example> The user's commands begin with @q<AT>, the modem's command introducer. The initialization string puts the modem in a known state, so that the software can control it properly. In the sample shown above, the @q<Z> resets the modem to default settings; @q<F1> puts it in full-duplex no-echo mode; @q<Q0> instructs it to produce result codes; @q<V1> specifies that the result codes should be words (for example, CONNECT or BUSY) rather than digits; @q<X1> selects the extended result code set (for example, CONNECT 1200); and @q<S0=0> disables auto-answer. Once initialized, the modem replies "OK", and the user types the dialing command ATDT followed by the phone number. When the other modem answers, the user sees the message "CONNECT 1200". Most software packages expect to be controlling a Hayes modem. The user simply supplies the telephone number; the software supplies the appropriate AT commands to the modem and interprets the modem's responses (OK, CONNECT, BUSY, NO ANSWER, etc.), all of which is invisible to the user. Packages like Smartcom (Hayes Microcomputer Products, Inc.) and Crosstalk (DCA/Crosstalk Communications) are able to present the user with a dialing directory, from which the user chooses the number to be dialed. The package does the rest. On the IBM 9751 CBX, call placement dialog is through Interactive Call Setup (ICS), which is markedly different from the Hayes dialog: @begin(enumerate,spread 0.5) The user selects the desired communications speed and parity (for example, 1.2 Kbit/s, even parity) and ensures that the personal computer is asserting the DTR signal. The user transmits a carriage return so the CBX can determine the transmission speed. ICS, after some delay, responds with "CALL, DISPLAY OR MODIFY?". The user should not transmit until this prompt has appeared. The user transmits "call 976543210" (or any desired number), followed by carriage return (the first two digits represent a request for an external line). There is a delay while the CBX attempts to make the connection. Various messages may appear, such as "CALLING 74250", which should be ignored. Characters transmitted to the CBX during this period will be lost. If the call was placed to a local host, and it was completed, the message "CALL COMPLETE" is issued, and the user is connected with the host. If the user was dialing out through the modem pool, the connection is made silently, with no call complete indication. If the connection could not be made, the message "CONNECTION FAILED" is issued. Characters may now be transmitted to the host computer. In most cases a carriage return is required to get the host's attention. @end(enumerate) @subheading(Making the Software Connection) In general, communication software packages can provide three ways to establish a connection to a remote computer: @begin(enumerate) @b<Direct>, meaning there is no dialing procedure. The user just "connects" and starts interacting with the remote computer immediately. This method is generally provided for use with PCs that are hardwired to computers with no intervening modems, but it allows the user to get at the dialing language of a modem (or data switch) that the package doesn't support. @begin<multiple> @b<Dialup>, usually configured for Hayes and/or other types of modems, where the user can configure the package to dial new kinds of modems (or data switches) not explicitly supported by the program. Since no known software package has built-in dial support for ICS, the dial feature can only be used with ICS if the user can tailor the dialing mechansism. The dial feature is important because it is often associated with a phone directory, in which each entry contains not only the phone number, but also the associated communications settings. @end<multiple> @begin<multiple> A @b<script>, in which the user writes a program in the package's script language to interact with a remote computer or other device either directly or through a modem. The script generates what the user would type, and reacts to responses the same way the user would. Scripts are important for two reasons. The first is convenience, since they allow routine, repetitive interactions to be done by the computer rather than the human. "Pushbutton" applications can be set up for administrative or data entry personnel to minimize training and headaches. The second reason, perhaps more important, is that scripts allow unattended operations. One computer can call up another when everyone is asleep and phone rates are low to transfer files or exchange mail. Networks like USENET and FIDO depend on this kind of unattended operation. @end<multiple> @end(enumerate) The communications software packages used at Columbia were checked for their ability to handle each of these methods. Several packages are discussed in detail but many more were evaluated (Table @ref<-foo>). If the package allows direct connection, then it may be used with the CBX. If the package includes a dial feature, then this was tested for adaptability to the CBX. Finally, if the package has a script language, scripts were written to place calls from the CBX through ICS. Note that scripts and certain dial commands depend on receiving a call completion indication from the "modem". Because the IBM 9751 CBX provides a CALL COMPLETE message when calling a local host, but not when dialing out through the modem pool, different methods must be used in each case. @subheading(MS-DOS KERMIT 2.31) Kermit is a file transfer protocol developed at Columbia University, so packages based on it are popular on campus. All Kermit programs support direct (no-modem) connections and thus work with the CBX. Many commercial communications packages incorporate the Kermit protocol, but this is no guarantee that they can be adapted to the CBX (although most of them can). The MS-DOS version of Kermit for the IBM PC and compatibles is used not only for file transfer but also for VT102 and Tektronix terminal emulation in hundreds of locations throughout the university. Like all Kermit implementations, MS-DOS Kermit is easy to install and run. No lengthy configuration dialog is required. The user simply starts the program, sets the minimum parameters necessary for communications (usually just speed and parity), and then uses the CONNECT command to begin terminal emulation. This allows immediate communication with whatever is connected to the PC's serial port: the PACX, a modem, or a ROLMphone (Fig. @ref<-msdialog>). @begin(figure) @bar() @blankspace(1) @begin<example> @i<(What the user types is underlined; a terminating carriage return is @~ implied).> A>@ux<kermit> IBM-PC Kermit-MS Version 2.31 Type ? or HELP for help Kermit-MS>@ux<set speed 2400> Kermit-MS>@ux<connect> @blankspace(0.5) @i<(User types a carriage return here)> @blankspace(0.5) CALL, DISPLAY OR MODIFY? @ux<call 976543210> @blankspace(0.5) @i<(User waits for a beep from the phone, then types carriage return.)> @blankspace(0.5) login: @end<example> @caption(MS-DOS Kermit Direct Connection to CBX) @tag<-msdialog> @bar() @end(figure) In addition, MS-DOS Kermit allows scripts to be written to automate any procedure that the user would do manually. For example, the script shown in Figure @ref<-mshayes> could be used to call the number 6543210 through the CBX and begin the login process on the remote computer. @begin(figure) @bar() @blankspace(1) @begin<example> set input timeout quit ; Quit if desired input doesn't appear set speed 1200 ; Set desired speed output \13 ; Carriage return (ASCII 13) wakes up ICS input 10 MODIFY? ; Wait up to 10 seconds for ICS prompt pause 1 ; Wait one second before replying output call 976543210\13 ; Call the phone number (97 dials outside) pause 20 ; Wait 20 seconds for completion output \13 ; Send a carriage return to the host input 20 login: ; Wait for "login:" prompt connect ; Let the user take over @end<example> @caption(MS-DOS Kermit Script for Dialing Out from the CBX) @tag<-mshayes> @bar() @end(figure) This script may be created using any text editor and saved in a file. The Kermit program can be instructed to execute the script file by using the TAKE command, specifying the file's name. The file can contain any valid Kermit commands, but the INPUT, OUTPUT, and PAUSE commands are special for scripts because they simulate what the user would do during terminal emulation. OUTPUT sends the characters that the user would type, and INPUT reads the characters that are received from the other computer, looking for the specified character sequence. The command SET INPUT TIMEOUT QUIT tells Kermit that if the requested input does not appear within the specified time interval, then the script should not be continued. These commands do what the user would do, so they perform a kind of "human emulation". When a call is made to a local computer attached as a host to the CBX, a CALL COMPLETE message is issued. The annoying twenty-second pause required in the dialup case is eliminated so that the script can proceed immediately upon receipt of the message (Fig. @ref<-mscomplete>). @begin(figure) @bar() @blankspace(1) @begin<example> output call myhost\13 ; Call the computer named is "myhost" input 20 CALL COMPLETE ; Wait up to 20 seconds for completion output \13 ; Send a carriage return to the host input 20 login: ; Wait for "login:" prompt connect ; Let the user take over @end<example> @caption(Taking Advantage of CALL COMPLETE) @tag<-mscomplete> @bar() @end(figure) A single script could be used in both cases, provided Kermit was instructed to allow for immediate response when the CALL COMPLETE message appears, and a mandatory pause when it does not (Fig. @ref<-mstimeout>). In this case, SET INPUT TIMEOUT QUIT is replaced with SET INPUT TIMEOUT PROCEED to tell Kermit not to give up if the expected output did not appear. @begin(figure) @bar() @blankspace(1) @begin<example> set input timeout proceed ; Ignore timeouts, keep going. input 20 CALL COMPLETE ; Wait up to 20 seconds for completion output \13 ; Send a carriage return to the host set input timeout quit ; From now on, quit script upon timeout input 20 login: ; Wait for "login:" prompt connect ; Let the user take over @end<example> @caption(Allowing for Local and Dialout Connections) @tag<-mstimeout> @bar() @end(figure) Kermit scripts illustrate the general characteristics of a script language: the ability to send characters to a remote device, to receive characters and compare them with a given pattern, to set time limits on selected operations, to pause for specified intervals, and to quit when the script is obviously not working. Scripts also include some kind of notation for special characters that could not be included otherwise, such as Kermit's @q<\13> for carriage return (13 is the ASCII value for that character). This has been a simple example of a script, but it's not very useful as it stands because it can be used only to dial a particular phone number. It would be much more convenient to be able to define a command, "dial," that would perform this procedure for any telephone number, and some script languages allow this. For example, Figure @ref<-mscommand> shows how this could be done in MS-DOS Kermit. @begin(figure) @bar() @blankspace(1) @begin<example> define dial set inp tim q,set sp 1200,out \13,in 10 MODIFY?,- pau 1,out call \%1\13,pau 20,out \13,in 20 login:,connect @end<example> @caption(Defining a New Kermit Command) @tag<-mscommand> @bar() @end(figure) Here the new command "dial" is defined to execute all the commands from the previous example (note how Kermit allows commands to be abbreviated), but with the desired phone number substituted for the formal parameter "@q<\%1>" at the time the command is executed, @w<a@ la> MS-DOS batch. With this definition in place, the Kermit user could type "dial 975551212" or "dial 34321" (a local extension), or any other number. For even greater brevity, the user could define shorthand commands to dial frequently used numbers: @begin<example> define d1 dial 975551212 define d2 dial 54321 @end<example> Kermit, like many other packages, will automatically execute any commands found in a special "initialization file" upon startup. This is a good place to keep definitions such as these, so that they will always be in effect every time you run the program. Scripts can also have features for decision making: For example, the Kermit script shown in Figure @ref<-msdecide> will work with either a Hayes modem or the IBM 9751 CBX. @begin(figure) @bar() @begin<example> ; A Kermit script that tries different dialing methods. ; First, define a command to handle dialing failure: define giveup echo Dialing failed, hangup, stop ; Now the script itself... set speed 2400 ; Set desired speed. :HAYES ; Let's see if it is a Hayes modem. output ATZ F1 Q0 V1 X1 S0=0\13 ; Initialize modem at this speed. input 10 OK ; Look for Hayes response. if failure goto cbx ; Not found, go try CBX dialing. echo Hayes dialing... ; It's Hayes, tell the user. output ATDT 97,555-1212\13 ; Dial the number and <CR>. input 30 CONNECT ; Look for modem's confirmation. if failure giveup ; Give up after waiting 30 seconds. reinput 3 2400 ; Was the message CONNECT 2400? if success goto good ; If so, we're ready to go. reinput 2 1200 ; No, how about 1200? if failure giveup ; Neither, so quit. set speed 1200 ; It was 1200, so adjust speed. goto good ; Go issue message and connect. :CBX ; Not a Hayes, so try CBX dialog. reinput 10 MODIFY? ; Look for CBX prompt. if failure giveup ; If not found, give up. echo CBX dialing... ; It's the CBX, tell the user. output call 975551212\13 ; Dial the number. pause 20 ; Wait for call to complete. :GOOD ; We got through, somehow. echo Connected! ; Display a message. connect ; Start terminal emulation. hangup ; When done, drop DTR to hang up. @end<example> @caption(A Kermit Script That Works With Both Hayes and CBX Dialing) @tag<-msdecide> @bar() @end(figure) This script works by issuing a Hayes command and looking for the OK response. If the OK response does not appear, then the script issues an ICS command instead. For Hayes modems, the script dials the number, and then looks for the Hayes CONNECT response. The full message should be CONNECT 1200 or CONNECT 2400. Even though the dialup speed is 2.4 Kbit/s, the modem on the other end may have answered at 1200, in which case the Hayes will automatically fall back to that speed, and inform the software in its CONNECT message. The "reinput" commands examine the previous material to see if it contained a "1200" or "2400", allowing Kermit to change its speed accordingly. With some extra work, this script could be reworked into a dial command similar to the one shown previously, so that it could be used for dialing any desired number. Finally, a script can contain looping constructs. For instance, if we wanted Kermit to try dialing three times before giving up, we could write a script program containing the SET COUNT and IF COUNT statements (Fig. @ref<-msloop>). @begin(figure) @bar() @blankspace(1) @begin<example> set count 3 ; Loop limit. goto first ; Skip pause on first try. :AGAIN ; Label for top of loop. echo Trying again... ; Tell the user what's happening. pause 30 ; Pause for 30 secs between calls. :FIRST ; Label for first try. dial 977654321 ; Try dialing. if success goto online ; If it worked, let user take over. if count goto again ; Otherwise try again. echo Try again later. ; If too many tries, give message, stop ; and stop. :ONLINE ; Get here on successful connection. echo Connected! ; Let user know. connect ; Begin terminal emulation. hangup ; Hang up when the user returns. @end<example> @caption(A Script That Keeps Trying) @tag<-msloop> @bar() @end(figure) The basic principles of manual connection and of script construction illustrated by Kermit apply also to many other popular communications packages, though the form and and range of options available can vary dramatically. @subheading<PROCOMM 2.2> ProComm 2.2 is a popular "shareware" communications package from DataStorm Technologies (Columbia, MD). Like Kermit, it does not require a lengthy configuration or installation procedure. After starting the program, you may begin terminal communications immediately, assuming the speed and parity are set appropriately. The command Alt-F10 displays a help screen, and Alt-P allows the alteration of communications parameters and with the option to save them in a file so that ProComm starts up with the desired settings thereafter. ProComm is perfectly suitable for "manual" use with the IBM switch. It is also possible to configure ProComm for automatic dialing through the switch, using either its built-in dialer support or its script language. To set up automatic dialing, type Alt-S, select (1) MODEM SETUP, and then set the following: @begin<enumerate> Modem initialization string: Just make it null (empty). Dialing command: "@q<!~~~~~~~~~~call >" (note the blank after "@q<call>"). The exclamation "@q<!>" is ProComm's notation for a carriage return (CR), and the tilde "@q<~>" is used by ProComm to represent a 1/2 second pause. This command sends the required CR, pauses 5 seconds, and then gives the CALL command. Connect string: "@q<CALL COMPLETE>" (only used for redialing) @end<enumerate> For dialing out from the CBX, omit the connect string to disable redialing since there would be no connect string in that case. This highlights the most basic difficulty in adapting software to the new environment. The switch does not inform the software in any way -- not by message, not by modem signal transition -- when the connection has been made. This fact, combined with the switch's built-in queuing for busy resources, renders useless the redial feature found in so many communications programs. Having defined a dialing command for the CBX, now type Alt-D and add the relevant phone number to the dialing directory. Then to dial a host, type Alt-D and select the number of its directory entry. Once these commands are debugged, the configuration can be saved by answering Yes to the question in the menu. Dialing is not reliable, however -- it just forges ahead without checking that valid responses are coming from the CBX. If the CBX is slow in responding to the initial CR, the CALL command will be issued prematurely and ignored by the CBX. Figure @ref<-procomm> shows a ProComm script that can be used to synchronize the call. @begin(figure) @bar() @blankspace(1) @begin<example> %E1 @i<(Emulate a VT100)> %F"3" @i<(2400 bps, even parity)> %U2 @i<(display carriage return as-is)> %U4 @i<(full duplex)> %T"^M" @i<(send a carriage return)> %I"CALL, DISPLAY OR MODIFY?" @i<(wait for prompt)> %T"call 976543210^M" @i<(issue CALL command, followed by CR)> %T"~~~~~~~~~~~~~~~~~~~~~~^M" @i<(pause, then send carriage return)> %I"login:" @i<(wait for the host's "login:" prompt)> @end<example> @caption(A ProComm Script for Use with the CBX) @tag<-procomm> @bar() @end(figure) The script file can be created with an editor and saved with a filetype of @q<.CMD>, and executed using Alt-F5. Unlike a Kermit script file, the ProComm script may not include comments. @subheading<CROSSTALK XVI VERSION 3.61> Crosstalk XVI is a popular commercial communication package for the IBM PC family. It is designed primarily to be used with modems, but it also allows direct connections. To use Crosstalk in direct mode to dial out through the CBX, type "xtalk" to start the program, and then, after the logo screen disappears and the status screen appears, type one or two carriage returns until you get the "Command?" prompt on the bottom line. At this point, use any of the two-letter commands listed on the top part of the screen to set the necessary communications parameters. For example, when connecting to a DEC VAX, type: @begin<example> SP 1200 @i<(Speed 1200 bps)> PA E @i<(Parity even)> DA 7 @i<(Seven data bits)> DU F @i<(Duplex Full)> EM VT @i<(Emulate a VT100 terminal)> @end<example> Then establish the connection as follows: @begin<example> @ux<GO LOCAL> @i<(Make the connection)> @i<(Type a carriage return)> CALL, DISPLAY OR MODIFY? @i<(Get CBX prompt)> @ux<call 976543210> @i<(Type the call command)> @i<(Type a carriage return)> login: @i<(Here's the VAX's login prompt)> @end<example> You can get back to Crosstalk by typing its attention character, normally Escape, and you can redefine the attention character with the AT command. Once you have got this procedure working, you can use the SA (save) command to save it in a file (for example, MYHOST, which is automatically created with the filetype @q<.XTK>) and it will appear in the startup menu, or you can run it at any time using the Crosstalk LOAD command. Crosstalk also lets you set up command files for dialing different computers. A Crosstalk command file is most easily created by editing a previously saved @q<.XTK> file. The trick is to replace the Hayes AT dialing commands with the switch's equivalents. Relevant commands are: @begin<example> Aprefix @i<(Remove the "Answer prefix")> NUmber 976543210 @i<("number" to dial for MYHOST)> DPrefix |~~~~~~~~~~call @i<(dial prefix: send CR, pause, then "call ")> DSuffix | @i<(dial suffix: carriage return)> GO @i<(dial the number)> @end<example> The vertical bar "@q<|>" is Crosstalk's symbol for carriage return, and each tilde means to pause for one second. Note that the dial prefix must have a space after the word "call". A Crosstalk command file is similar to a ProComm dial entry and has the same drawback -- if the hard-coded pause interval is not long enough, then the "call" command will be sent before the CBX is ready for it. To circumvent this difficulty, you can write a Crosstalk script to synchronize and verify the call setup procedure (Fig. @ref<-xtalk>). @begin(figure) @bar() @blankspace(1) @begin<example> go local @i<(connect directly to ICS)> wait delay 10 @i<(wait one second)> reply | @i<(send a carriage return)> wait string "MODIFY?" @i<(wait for prompt)> reply call 976543210| @i<(dial the number)> wait delay 200 @i<(pause 20 seconds)> reply | @i<(send a carriage return to UNIX)> wait string "login:" @i<(wait for UNIX "login:" prompt)> @end<example> @caption(A Crosstalk XVI Script) @tag<-xtalk> @bar() @end(figure) The easiest way to make a Crosstalk script file is to copy a command file to another file with filetype @q<.XTS> and then use an editor to replace the GO command with script commands. A script may be executed at any time using the Crosstalk DO command. @subheading<SMARTCOM II VERSION 2.2> Smartcom is a Hayes product for the IBM PC family designed for use with Hayes modems. Fortunately, it also allows for direct connections, which are the "back door" into the CBX. You cannot do automatic dialing of the CBX with Smartcom (except through a 244PC), because the only dialing devices it supports are those made by Hayes. Smartcom II searches for a Hayes modem connected to one of the ports, but since your PC is now connected to a ROLMphone, the program eventually gives up with a message "Smartmodem not responding". At that point, you can get into the main menu by pressing the F1 key. Configuration is a rather involved affair: choose "2" from the main menu (Edit Set), then choose one of the predefined Setups (Set), then F1 back to the "Edit Set" menu, then choose "Parameters", and then specify that the connection type is DIRECT, and modify the speed, parity, and other communications parameters as required. Then select "begin communication". At this point, you may type carriage return to get the "CALL, DISPLAY OR MODIFY?" prompt, and type the desired "call" command. The ICS dialog may be automated by the use of a "macro." To define a macro you must visit the menus again: from the main menu select 2 (Edit Set), then from the Edit Set menu choose S (which Set to edit), and then choose the unused set X. Then select M to define a macro and then Z to assign it the label Z (automatic logon). At this point Smartcom II presents you with a table, which you fill in (Fig. @ref<-scom2>). @begin(figure) @bar() @blankspace(1) @begin<example> MACRO DEFINITION Press F2 For Help Name Of Macro: Z - Automatic Logon Set X - Unused @ux< Time-out Prompt Data Send CR> 0 0 (off) YES 20 63 ("?") call myhost YES 20 69 ("E") NO 2 69 ("E") YES 10 58 (":") NO @end<example> @caption(A SmartCom II Macro) @tag<-scom2> @bar() @end(figure) The columns read across, Wait this long (Time-out) to get this character (Prompt) from the remote system, and then if the desired character arrives or if the time limit expires, send this character string (Data), followed by a carriage return if (Send CR) is YES. In the example, the first line waits no time for nothing, then sends nothing followed by a carriage return. Then Smartcom waits up to 20 seconds for the question mark from the CBX's @q<CALL, DISPLAY OR MODIFY?> prompt. Prompts can be single characters only, and are indicated by the decimal ASCII value. When the prompt arrives (or the timer goes off) Smartcom sends the text "call myhost" followed by a carriage return. In this example, we are showing a call to a local host rather than a dialout call, to illustrate an item of interest. We want to wait for the "CALL COMPLETE" message before sending a carriage return to the host to get its "login:" prompt. But Smartcom II macros only let us look for single characters, not words or phrases. And the phrase "CALL COMPLETE" has two E's in it. So the script waits up to 20 seconds for the first E (allowing time for call placement) and sends nothing. Then it waits 2 seconds for E number two, responds with a carriage return, then waits 10 more seconds for the colon "@q<:>" from the "@q<login:>" prompt. For dialing out, the switch does not give us the CALL COMPLETE indication, so the last three lines of the table would be omitted, and "myhost" would be replaced by a telephone number. Once the table is filled in correctly and tested, it can be saved by typing ESC and then R (Record); it will appear on the Set X macro menu the next time you run Smartcom II. Smartcom II is not the only package that restricts input matching to single characters. VTERM III, from Coefficient Systems (New York City), works the same way. In that package, scripts are assigned to function keys, which the user has to press, e.g. @example[Shift F1: <CR><W:?><P:1>call 976543210<CR><P:10>] Which means send a CR, Wait for a question mark (the one in "MODIFY?"), pause 1 second, send the call command and a carriage return, and then Pause for 10 seconds. @subheading<SMARTCOM III VERSION 1.0A> Like Smartcom II, Smartcom III can be used with either Hayes modems or direct connections. Before you can communicate, you have to go through a configuration process that is not entirely intuitive. First, you must define an "Activity" @i<and> a "Connection." Each has a menu and several submenus that must be traversed. For each, choose New to create a new entry, and give it a name, go through the menus and make the appropriate choices, and then press F8 to save it. An Activity contains information that applies to the host or service you're connecting to: what kind of terminal to emulate, what the terminal settings should be, which file transfer protocol to use, how to set up your keyboard, etc. For example, you might create an Activity called VAX, in which you emulate a VT-102 terminal in full duplex, and use the Kermit protocol for file transfer. A Connection contains the data communication parameters: the communication port, speed, parity, data bits, etc. The key item here is Type of Connection: you must specify Direct. For example, you might create a Connection called CBX, which specifies Direct, COM1, 2400 bps, even parity, 7 data bits. Having created an Activity and a Connection, you can return to the main menu and select Initiate a Session. Smartcom will give you menus of all the available Activities and Connections, and you must choose one from each. Having done all of this (it won't take more than half an hour!), you may now begin to communicate with the switch. Type carriage return in the normal way, get the CALL, DISPLAY OR MODIFY? prompt, and you're on your way. In the future, you can take advantage of the configuration work you've done by invoking the program with the Activity and Connection name on the command line, as in @begin<example> C>@ux<scom3 vax.cbx> @end<example> Like Smartcom II, Smartcom III includes a large dialing directory, listing major services like Compuserve, Dow-Jones, The Source, MCI Mail, etc. Presumably, access to these services is one of the reasons you bought Smartcom. How can you continue to dial them from your new CBX phone? Smartcom III includes a script language as well as a remarkable feature called "learned scripts". When you turn on script learning (from the session menu), it will observe both what you typed in and the responses that come back. It then translates the observed interactions into a program in Smartcom III's script language, SCOPE. Figure @ref<-scom3> shows an example for logging into MYHOST through the CBX. @begin(figure) @bar() @blankspace(1) @begin<example> { Smartcom III Learned Script 7/19/88 7:28 PM } TYPE KEY RETURN_KEY ; WAIT FOR PROMPT "CALL, DISPLAY OR MODIFY?" , 10 ; TYPE LINE "call myhost" ; WAIT FOR PROMPT "CALL COMPLETE" , 20 ; TYPE KEY RETURN_KEY ; WAIT FOR PROMPT "login:" , 20 ; @end<example> @caption(A SmartCom III Learned Script) @tag<-scom3> @bar() @end(figure) Note that Smartcom automatically discarded the lines (like "CALLING 74250") that did not evoke user typein, and it timed the responses. The same script should work for dialing (substituting the phone number for "myhost".) If the CALL COMPLETE message fails to appear within 20 seconds, the script will go on to the next statement. How can this script be combined with our predefined Activities? Just give the script the same name as the Connection that you use to get to that Activity, in our case "CBX". Whenever you establish a "CBX" Connection, the script executes automatically, and dialing up your favorite service with Smartcom III is as painless with the CBX as it was with a Hayes modem. @subheading<OPEN ACCESS II> Open Access II, from Software Products International (San Diego, CA), is one of those all-in-one packages for the IBM PC family -- spreadsheet, database, word processor, clock-calendar, and communications. The packages we've looked at so far were intended only for communications, so as a last resort their users could always convert to another package if the CBX conversion posed insurmountable problems. But when communications is only an ancillary function of a larger package, switching packages may not be an option. The communication feature of Open Access II supports direct mode, as well as user-defined modem dialing sequences. But these cannot be used right away. Rather, one must go through an intricate and time-consuming menu-driven configuration session. But after sufficient effort, it can be made to work with the switch, at least in direct mode. Here's how: Select Communications from the main menu, then select Modem from the communications menu. When it prompts you for a modem name, say NOMODEM. Then select Format and set the desired speed, parity, data, and stop bits. Then go back to the Modem menu and select Miscellaneous Parameters. Be sure to set "Translate modem character" to No. Now go back to the Communications menu and select the Service Menu. Make a new service called, say, CBX. Select the Format menu, and make all the format items agree with the modem formats (if they do not agree, the connection will not work). Now go back to the Service menu and select the Miscellaneous Parameters menu. Several important settings here are: Autodial No, Hangup on Exit No, Ignore CTS Yes, Ignore Linefeed Yes (if the latter is set to No, then the program will send CR LF whenever you type carriage return, and you will not be able to have a successful dialog with ICS). Pop back up two levels to the Communications menu, select Terminal, and now you can interact with ICS. Wasn't that easy? Of course it wasn't. But preserving the user's investment in an expensive multifunction package can be worth the extra effort. In any case, if adaptation to the CBX's Interactive Call Setup dialog had not proved possible for Open Access II, then it would still have been possible to keep the package, but to use a separate package for communications, or to offer the user the more expensive 244PC ROLMphone alternative. @subheading<Another Package, Another Trick> One package we looked at, VsCom, for use between IBM PCs and Wang VS systems, allows direct connections, user-defined dialing sequences, and scripts. Direct connection worked fine on the first try. The evaluation copy of this program came without a complete manual; script file information was not available, nor was a listing of what special characters were allowed in the dialing sequence, for instance to signify pauses. Experimentation did not uncover a pause character. The sample screen showed that "@q(<CR>)" stood for carriage return, so the following dialing string was used: @begin<example,leftmargin 0> <CR>@>call myhost<CR> @end<example> The dialing string has to fit on one line, so the maximum number of spaces were inserted between the initial carriage return and the "call" command. These serve as "padding," or time wasters, to give the switch time to issue its "@q<CALL, DISPLAY OR MODIFY?>" prompt before sending the "call" command. Luckily, the switch ignores leading spaces, otherwise this trick would not have worked. @subheading<Macintoshes, T-Switches, and DTR> The RS-232-C Data Terminal Ready (DTR) signal is sent from the PC to the ROLMphone to let the CBX know that the PC ready to communicate. This allows software packages to request service by turning on the DTR signal, and to close a connection by turning DTR off. However, certain packages or PCs cannot control their DTR signals. For this reason, the switch's data lines may be configured with "Forced DTR," which means that the switch will pretend the DTR signal is always on, at the expense of software-controlled call establishment and release. The problem is that Forced DTR is not a user-settable parameter. Rather, it must be configured by the CBX management, an administrative procedure that entails a fee, the filling out of forms, and some days of waiting for the request to be processed. Furthermore, the whole concept is intrinsically baffling to users. Therefore, it was decided that all lines should be configured the same, without Forced DTR. But then what is to be done about devices that can't turn DTR on and off at will? There are two striking examples. First is the Apple Macintosh, which is quite popular at Columbia. But the Mac's serial communications interface is not RS-232-C, but rather an RS-422 device that is @i<simulating> RS-232-C. This interface does not provide any modem signals, in particular DTR. Second is the ever-popular T-switch (sometimes called an A-B switch): users who have a PC connected to both a ROLMphone and some other device through a T-switch lose their data connection as soon as they switch their device away from the phone. Clearly, one does not want to submit a "move-and-change" order every time one turns one's T-switch from A to B, or exchanges a PC for a Macintosh. Our solution to this problem was to build special RS-232-C adapters that go between the phone and the user's cable. These loop one of the phone's constant outputs -- either Pin 9 (Positive DC Test Voltage) or Pin 5 (Clear to Send), depending on the phone model -- back into the phone's DTR input. These adapters are called FOTs ("Fake Out Things"), Models A and B, shown in Figure @ref<-fot>. The male end connects to the phone, the female end to the user's cable. The FOT is analogous to a null modem, in that it tricks the phone into thinking a computer is connected. One might call it a "null computer." @begin(figure) @bar() @blankspace(1) @begin<example> Male Female Male Female FG 1----------1 (Frame Ground) TD 2----------2 (Transmitted Data) FG 1----------1 RD 3----------2 (Received Data) RD 2----------2 RTS 4----------4 (Request to Send) TD 3----------3 CTS 5----------5 (Clear to Send) RTS 4----------4 DSR 6----------6 (Dataset Ready) CTS 5---+ 5 SG 7----------7 (Signal Ground) | CD 8----------8 (Carrier Detect) DSR 6----------6 DC+ 9---+ 9 (Test Voltage) | | SG 7----------7 DTR 20---+ 20 (Data Terminal Ready) | RI 22----------22 (Ring Indicate) CD 8----------8 | DTR 20---+ 20 RI 22----------22 Model A Model B @end<example> @caption(The FOT) @tag<-fot> @bar() @end(figure) Once we discovered how to connect Macs to the phone, we found that all popular Macintosh packages were able to use the CBX in direct mode, and some also in dial or script mode, depending on the capabilities of the package (see Table @ref<-foo>). @subheading<Hard Cases> WilsonLine, a product of the H.W@. Wilson Company (Bronx, NY), is a CD-ROM database package used primarily in libraries, which also dials out to a central database service for updated information. It is a turnkey system that performs a unique function in a proprietary manner, and includes a non-customizable communication feature. Only a Hayes 300 or 1200 bps modem can be used. Wilsonline cannot be used for direct computer connections, nor with non-Hayes modems or with data switches. Our libraries depend on this package. For them, the only solution is the costly 244PC, a ROLMphone which emulates a Hayes 1200 Smartmodem. We also learned that certain "bank at home" products could not be made to work with the CBX, except with a 244PC. Packages like Chemical Bank Pronto, and Citibank Direct Access only work with modems certified and approved by the bank, and the IBM 9751 CBX is not on their list (nor, in all likelihood, are any other data PBX's). But other banking packages like Chase Manhattan Spectrum can be used with "dumb" (nondialing) modems, and therefore also with the CBX. @subheading<Summary> Your organization is installing a new digital voice/data switch. If you have any choice in the selection, you should look for features that will allow the popular RS-232-C communications packages to continue working. A Hayes-compatible dialing language would be a good start, especially if it is not an extra-cost option. Also, as we've seen, some kind of call completion indication is essential to the reliable operation of scripts. This can be in the form of a message, or the transition of the Carrier Detect modem signal from low to high. To prepare users of communication packages for conversion to the switch, first find some way to explain to them why they won't be needing their modems any more. Be positive -- tell them they can take their modems home and dial in to work from there. If the switch claims to provide the Hayes dialing language, test it with a few packages, preferably Smartcom II or III (if any package knows how to exercise a Hayes modem, Smartcom should!). If it works, you're done. If your switch has its own special dialing language, you'll have to go through the same procedure we did. Conduct a survey of your users to find out what packages they are actually using. Get copies of each package, along with the manuals. First find out if the package can be used in direct interactive mode. This can be tricky, because most packages are designed to be used with modems. A PC connected directly to a timesharing computer must be a relatively rare phenomenon judging from the scant attention given to this setup by most package manuals. But this is the back door to the data switch, so you must persist till you find it. In packages like Smartcom and Open Access, you may find yourself knee deep in menus before the magic door appears, but in almost every case it's there. Sometimes near the surface, sometimes deeply buried or cleverly disguised. All those prompts about modem initialization strings, dialing strings, dialing prefixes and suffixes are ruses and red herrings, irrelevant to direct connections. Eradicate them if you can. If you find a configuration item that says "modem type," and one of the choices is "direct" or "no modem," then you're home free. Try the package interactively in this mode, and it should work. If the package appears not to support direct connections, you might still get it to work with your switch provided you can supply the required RS-232-C modem signals. For example, if the software refuses to communicate unless it receives the Carrier Detect (CD) signal from the modem, you can trick it by feeding its own Data Terminal Ready (DTR) signal back into its CD signal (by connecting pins 8 and 20 together in the PC end of the RS-232-C cable). Then try the package's dial feature, if it has one. It's nice to get this working, because then the software package's dialing directory can be used to make outgoing data calls through the switch, in the same way it can be used with a modem. This time, try replacing the dial initialization string or prefix with the one used by your switch. In the IBM 9751 CBX case, the initialization string was a carriage return, and the dial prefix was the word "call" followed by a space. The dial suffix, if required, is normally a carriage return. In our case, we needed a pause after the initial carriage return to give the switch time to issue its prompt. Finally, try setting up a script, if the package has a script language. This will get your turnkey and pushbutton users off the ground, and it will allow any unattended operations to continue unabated. Some script languages are straightforward, others are best understood by a devious mind. In the latter category come scripts of the "expect-send" variety (like Smartcom II), which assume that something must be received before anything can be sent, and scripts that only match single characters, rather than whole strings, from the input stream (like Smartcom II or VTERM II). Table @ref<-foo> summarizes the results for the packages we looked at. We found that nearly all of them allow direct connections, and so can be made to work with with IBM's CBX. Getting the CBX's dialing to mesh with the package is somewhat more problematic. But in all cases, it seems that if the package has a script language, @i<and> it supports direct-mode connections, then scripts can be written to dial out from the CBX. So the news is almost completely good. @begin<table> @bar() @blankspace(1) @begin<format,leftmargin +4> @tabclear()@tabset(1.6inch,2.5inch,3.5inch,4.4inch,5.3inch) @case(device,file="@\@\@\@ux<Operates with CBX using....@*>", else="@\@\@\@ux<@ @ @ @ @ Operates with CBX using....@ @ @ >@*") @\@\@\Direct@\DIAL@\Script @ux<Package@\Version@\System@\Connect@\Command@\Language> @tabclear()@tabset(1.8inch,2.5inch,3.75inch,4.65inch,5.55inch) Crosstalk XVI@\3.61@\IBM PC@\Y@\Y@\Y Crosstalk Mk.4@\1.01@\IBM PC@\Y@\Y@\Y Dialoglink@\1.20@\IBM PC@\Y@\Y@\N Direct Access@\---@\IBM PC@\N@\N@\N Hyperaccess@\3.11@\IBM PC@\Y@\N@\Y MS-Kermit@\2.31@\IBM PC@\Y@\N@\Y Open Access@\II@\IBM PC@\Y@\N@\N PC-Plot@\3.601@\IBM PC@\Y@\N@\N PC-TalkIII@\---@\IBM PC@\Y@\N@\N ProComm@\2.2@\IBM PC@\Y@\Y@\Y Pronto@\---@\IBM PC@\N@\N@\N Smartcom II@\2.2@\IBM PC@\Y@\N@\Y Smartcom III@\1.0A@\IBM PC@\Y@\N@\Y Spectrum@\2.1@\IBM PC@\Y@\N@\N VsCom@\4.5@\IBM PC@\Y@\Y@\N VTERM III@\1.2@\IBM PC@\Y@\Y@\Y Wilsonline@\1.19@\IBM PC@\N@\N@\N ZCOMM@\3/88@\IBM PC@\Y@\Y@\Y MacKermit@\0.9@\Macintosh@\Y@\N@\N MacTerminal@\2.2@\Macintosh@\Y@\N@\N Microphone II@\2.0@\Macintosh@\Y@\Y@\Y Red Ryder@\10.0@\Macintosh@\Y@\N@\Y VersaTerm-PRO@\2.00@\Macintosh@\Y@\Y@\Y Kermit-65@\3.81@\Apple II@\Y@\N@\N Kermit-80@\4.09@\CP/M systems@\Y@\N@\N Xmodem et al@\---@\CP/M, MS-DOS@\Y@\N@\N CX@\---@\DECmate@\Y@\N@\N Easycom@\---@\DECmate@\Y@\N@\Y C-Kermit@\4E@\UNIX, VMS@\Y@\N@\Y tip@\---@\UNIX@\Y@\Y@\N cu@\---@\UNIX@\Y@\Y@\N UUCP@\---@\UNIX@\Y@\N@\Y Kermit-11@\3.58@\DEC PDP-11@\Y@\Y@\Y Kermit-20@\4.2@\DECSYSTEM20@\Y@\N@\Y Kermit-32@\3.3@\DEC VAX/VMS@\Y@\N@\N @end(format) ("---" means version number not announced or relevant) @caption<Package Summary> @tag(-foo) @bar() @end(table) @subheading(Products Mentioned) The IBM 9750 Business Communication System is a product of IBM, 4900 Old Ironsides Drive, Santa Clara, CA 95054. CrossTalk XVI is a product of Microstuf Inc, 1000 Holcomb Woods Parkway, Roswell, GA 30076. There is now a newer product, Crosstalk Mk.4, from DCA/Crosstalk Communications, same address. Kermit is available for more than 300 different machines and operating systems from Kermit Distribution, Columbia University Center for Computing Activities, 612 West 115th Street, New York, NY 10025. Open Access II is a product of Software Products International, 10240 Sorrento Valley Road, San Diego, CA 92121. PACX IV is a product of Gandalf Data, Inc., US office: 1020 South Noel Avenue, Wheeling, IL 60090. ProComm 2.2 is a shareware product from DataStorm Technologies, PO Box 1471, Columbia, MD 65205. There is also a newer product, ProComm Plus. Smartcom II and III are products of Hayes Microcomputer Products Inc, 705 Westech Drive, Norcross, GA 30092. VsCom is a product of M/H Group, 222 West Adams, Chicago, IL 60606. VTERM III is a product of Coefficient Systems, 611 Broadway, New York, NY 10012. WilsonLine is a product of the H.W@. Wilson Company, 950 University Avenue, Bronx, NY 10452. @subheading<Glossary> @b(244PC) - A four-line data-equipped ROLMphone that includes a Hayes AT command language interpreter. @b(ASCII) - American Standard Code for Information Interchange, ANSI X3.4-1977. The 7-bit code used by most asynchronous terminals and personal computers for character storage and transmission. @b(CBX) - Computerized Branch Exchange, a family of digital voice/data private branch exchanges manufactured by Rolm and IBM. @b(CR) - Carriage Return, ASCII character 13. @b(CTS) - Clear To Send, an RS-232-C signal sent on pin 5 of the standard 25-pin connector by a modem to a computer or terminal, indicating that the computer or terminal has permission to send data to the modem. @b(DTMF) - Dual Tone Multi-Frequency (Touch Tone). @b(DTR) - Data Terminal Ready, an RS-232-C signal sent on pin 20 of the standard 25-pin connector by a computer or terminal to a modem, indicating that the computer or terminal is online. @b(Host) - A computer capable of supporting multiple simultaneous interactive users. @b(ICS) - Interactive Call Setup, the set of prompts and commands provided to the data user by the IBM 9751 CBX. @b(LDS-125) - A limited distance modem used with the Gandalf PACX IV data PBX. @b(LF) - Linefeed, ASCII character 10. @b(PACX) - The Gandalf Private Automated Computer Exchange, a data switch. @b(PBX) - Private Branch Exchange, a generic term for any device that switches voice or data calls. @b(PC) - Personal computer. @b(ROLMlink) - The proprietary protocol used between the ROLMphone and the IBM 9751 CBX, allowing simultaneous transmission of voice and RS-232-C data over a single pair of telephone wires. @b(ROLMphone) - A digital telephone for use with the IBM 9751 CBX. When equipped with the data option, capable of simultaneous voice and data connection. @subheading<Biographies> Christine Gianone is Kermit Administrator of Columbia University's Center for Computing Activities (CUCCA); Frank da Cruz is CUCCA's Senior Planning Officer for Networks, and author of @i<Kermit, A File Transfer Protocol>. Chris and Frank are also data communications instructors in Columbia's Division of Special Programs, and co-authors of various articles and a forthcoming book on data communications software and protocols.